The possibility to determine the position of a mobile device has enabled application developers and wireless network operators to provide location based and location aware services. Examples of such services include guiding systems, shopping assistance, friend finder, presence services, community and communication services and other information services giving the mobile user information about their surroundings.
In addition to the commercial services, governments in several countries have put requirements on the network operators to be able to determine the position of an emergency call. For instance, governmental requirements in the USA (FCC E911) specify that it must be possible to determine the position of a certain percentage of all emergency calls. The requirements do not differentiate between indoor and outdoor environment.
In many environments, the position can be accurately estimated by using positioning methods based on Global Positioning System (GPS). However, GPS-based positioning often have unsatisfactory performance in some areas such as urban or indoor environments. Complementary positioning methods could thus be provided by a wireless network. In addition to UE-based GNSS (including GPS), the following methods are available in the LTE standard for both the control plane and the user plane:                Cell ID (CID);        E-CID, including network-based AoA;        A-GNSS (including A-GPS);        Observed Time Difference of Arrival (OTDOA);        UL Time Difference of Arrival (UTDOA)—being currently standardized.        
TDOA-/TOA-Based Methods (e.g., OTDOA, UTDOA or GNSS/A-GNSS):
A typical format of the positioning result is an ellipsoid point with uncertainty circle/ellipse/ellipsoid which is the result of intersection of multiple hyperbolas/hyperbolic arcs (e.g., OTDOA) or circles/arcs (e.g., UTDOA, GNSS, or A-GNSS).
Hybrid Methods:
Since the hybrid technique involves a mix of any of the methods above, the position result can be any shape, but in many cases it is likely to be a polygon.
Cellular positioning methods rely on knowledge of anchor nodes' locations, e.g., eNodeB or beacon device locations for OTDOA, LMU antenna locations for UTDOA, eNodeB locations for E-CID. The anchor nodes' location may also be used to enhance AECID, hybrid positioning, etc.
Positioning Protocols and Architectures
The three key network elements in an LTE positioning architecture are the LCS (Location Services) Client, the LCS target and the LCS Server. The LCS Server is a physical or logical entity managing positioning for a LCS target device by collecting measurements and other location information, assisting the terminal in measurements when necessary, and estimating the LCS target location. A LCS Client is a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more LCS targets, i.e., the entities being positioned. LCS Clients may reside in a network node, external node, PSAP, UE, radio base station, etc., and they may also reside in the LCS targets themselves. An LCS Client (e.g., an external LCS Client) sends a request to LCS Server (e.g., positioning node) to obtain location information, and LCS Server processes and serves the received requests and sends the positioning result and optionally a velocity estimate to the LCS Client.
Position calculation can be conducted, for example, by a positioning server (e.g., E-SMLC or SLP in LTE) or UE. The latter corresponds to the UE-based positioning mode, whilst the former may be network-based positioning (calculation in a network node based on measurements collected from network nodes such as LMUs (Location Measurement Unit) or eNodeBs), UE-assisted positioning (calculation is in a positioning network node based on measurements received from UE), LMU-assisted (calculation is in a positioning network node based on measurements received from LMUs), etc.
FIG. 1a illustrates the UTDOA architecture being currently discussed in 3GPP. Although UL measurements may in principle be performed by any radio network node (e.g., eNodeB), UL positioning architecture may include specific UL measurement units (e.g., LMUs) which e.g., may be logical and/or physical nodes, may be integrated with radio base stations or sharing some of the software or hardware equipment with radio base stations or may be completely standalone nodes with own equipment (including antennas). The architecture is not finalized yet, but there may be communication protocols between LMU and positioning node, and there may be some enhancements for LPPa or similar protocols to support UL positioning.
A new interface, SLm, between the E-SMLC and LMU is being standardized for UL positioning. The interface is terminated between a positioning server (E-SMLC) and LMU. It is used to transport SLmAP protocol (new protocol being specified for UL positioning) messages over the E-SMLC-to-LMU interface. Several LMU deployment options are possible. For example, an LMU may be a standalone physical node, it may be integrated into the eNodeB or it may be sharing at least some equipment such as antennas with the eNodeB—these three options are illustrated in the FIG. 1a. 
LPPa (LPP annex) is a protocol between eNodeB and LCS Server specified only for control plane positioning procedures, although it still can assist user plane positioning by querying eNodeBs for information and eNodeB measurements. LPPa may be used for DL positioning and UL positioning.
In LTE, UTDOA measurements, UL RTOA, are performed on SRSs (Sounding Reference Signal). To detect an SRS signal, LMU needs a number of SRS parameters to generate the SRS sequence which is to be correlated to received signals. The SRS parameters used for generating the SRS sequence and determining when SRS transmissions occur may be provided in the assistance data transmitted by positioning node to LMU; these assistance data would be provided via SLmAP. However, these parameters may generally be not known to the positioning node, which needs then to obtain this information from eNodeB configuring the SRS to be transmitted by the UE and measured by LMU; this information would have to be provided in LPPa.
For DL positioning, LPP (LTE positioning protocol) has been standardized in LTE. LPP may be used over control plane or user plane connection (e.g., SUPL). LPP may also include elements-extensions such as LPPe (LPP extensions). FIG. 1b illustrates a DL positioning architecture.
LTE Positioning Protocol (LPP) is a positioning protocol for E-UTRAN control plane defined by 3GPP TS 36.355, the entire contents of which is hereby incorporated by reference. However, LPP has been designed in such a way that it can also be utilized outside the control plane domain such as in the user plane in the context of SUPL (Secure User Plane Location). LPP is currently used for DL positioning.
LPP elementary messages (Request and Provision of Capabilities and Location Information and Assistance Data) each include a container, an EPDU, which can be used by standardization for outside 3GPP to define their own extensions to LPP messages, or LPPe. OMA (Open Mobile Alliance) LPP Extensions take advantage of this option.
A variety of known and emerging positioning technologies are not in the scope of 3GPP work. This is natural because control plane deployments are typically bandwidth-constrained and limited to access types that are part of the control plane system. However, the user plane does not have any such limitations and, hence, new positioning technologies improving accuracy, availability and integrity can be realized in the user plane.
LPPe may be used, e.g., for operator-specific assistance data or assistance data that cannot be provided with LPP or to support other position reporting formats or new positioning methods. LPPe also reduces standardization work load and is applicable to both control and user plane.
A positioning result is a result of processing of obtained measurements, including Cell IDs, power levels, received signal strengths, etc., and it may be exchanged among nodes in one of the predefined formats. Positioning result may be based on measurements from more than one positioning methods. In 3GPP, the signaled positioning result is represented in a predefined format corresponding to one of the seven GAD shapes. Currently, the positioning result may be signaled between:                LCS target (e.g., UE) and LCS server, e.g., over LPP protocol;        Positioning servers (e.g., E-SMLC and SLP), over standardized or proprietary interfaces;        Positioning server and other network nodes (e.g., E-SMLC and MME/MSC/GMLC/086M/SON/MDT);        Positioning node and LCS Client (e.g., between E-SMLC and PSAP or between SLP and External LCS Client or between E-SMLC and UE).In emergency positioning, LCS Client may reside in PSAPs.        
Positioning result is often based on radio measurements (e.g., timing measurements such as timing advance and RTT or power-based measurements such as received signal strength) received from measuring radio nodes (e.g., UE or eNodeB or LMU).
In the uplink, measurements for UL positioning (e.g., UTDOA) are performed on UL transmissions, which may include, e.g., reference signal transmissions or data channel transmissions. UL Relative Time of Arrival (RTOA) is the currently standardized UTDOA timing measurement. The measurement may be performed on Sounding Reference Signals (SRS), which may be configured for periodic transmissions, typically comprising multiple transmissions but may also be a single transmission. SRS transmissions may be triggered by any of the two trigger types:                Trigger type 0: higher layer signaling from eNodeB;        Trigger type 1: via DL control channel signaling (DCI formats 0/4/1A for FDD and TDD and DCI formats 2B/2C for TDD).        
In the current standard, user plane positioning is used for DL positioning, whilst control plane positioning may be used for DL positioning and UL positioning.
Secure User Plane Location (SUPL) is a positioning service/architecture defined by OMA (Open Mobile Alliance, a mobile communications industry forum that was created to bring open standards, platform independence, and global interoperability) over a user plane bearer, such as IP, to aid network and SUPL Enabled Terminal (SET) based positioning technologies in the calculation of a SET's position. An example OMA positioning architecture is illustrated in FIG. 2.
SUPL includes but is not limited to the definition of a Location User Plane (Lup) Reference Point and corresponding interface between the SUPL Location Platform (SLP) and SET, security functions (e.g., authentication, authorization), charging functions, roaming functions, and privacy functions. SUPL utilizes existing standards where available and possible, and SUPL should be extensible to enable more positioning technologies as the need arises, so that they can utilize the same mechanism. Since there is no signaling dependency on core network or radio access network, the basic positioning architecture is similar to control plane in essence but much simpler.
Example of a typical Network-Initiated positioning flow is illustrated in FIG. 3:                A. The SUPL agent issues an MLP SUR message to the H-SLP;        B. The H-SLP initiates a SUPL session with the SET by sending a ULP SUPL INIT message. The message contains requested positioning method;        C. When the ULP SUPL INIT is received by the SET, it establishes a secure connection to the H-SLP;        D. The SET then sends a ULP SUPL POS INIT message to start a positioning session with the H-SLP. The message contains the SET capabilities;        E. The H-SLP then determines the positioning method and exchanges several successive ULP SUPL POS messages, containing the used positioning protocol (i.e., RRLP, RRC, TIA-801), as needed to determine the position;        F. When the position calculation is complete, the H-SLP sends the ULP SUPL END message to the SET informing it that the SUPL session is finished. The SET then releases the secure connection to the H-SLP;        G. The H-SLP sends the position estimate back to the SUPL agent in an MLP SLIA message.        
ULP can use other positioning protocols as payload including RRLP, LPP, TIA-801 etc. It can also convey on LPPe, which is an extension to LPP but defined and maintained by OMA.
In 3GPP, the user plane communication is via gateways (serving gateway, SGW, and PDN gateway, PGW) which are typically between the serving eNodeB and the SLP, and SUPL is between the UE (SET) and SLP. In a general user plane protocol stack, SUPL occupies the application layer with LPP transported as another layer above the SUPL. After establishing a TCP/IP connection (for a SET-initiated case) and initiating the SUPL and then LPP sessions, the flow of LPP messages (which may also contain LPPe) can be very similar to the control plane version of LPP (except for duplicate detection and retransmission as defined in 3GPP TS 36.355, since the MME (Mobility Management Entity) does not provide reliable and in-sequence delivery of LPP message), just with the SUPL Enabled Terminal (SET) as the LCS target and the SUPL Location Platform (SLP) as the LCS server.
Network Sharing
3GPP network sharing architecture allows different core network operators to connect to a shared radio access network. The operators may share the radio network elements, and may also share the radio resources themselves.
Network-sharing scenario allows operators without a UMTS/LTE license to share the network and supply its customers with 3 G/4 G services. For example, a 2 G operator may supply its subscribers with 3 G/4 G services using another operator's allocated spectrum.
Two architectures with radio access sharing exist. In the first architecture (aka Gateway Core Network (GWCN) configuration), MME is shared in addition to the radio access network (E-UTRAN) being shared. See FIG. 4a. In the second architecture (aka Multi-Operator Core Network (MOCN) configuration), which is an easier option, only the radio access network (E-UTRAN) is shared. See FIG. 4b. In both configurations, the UE behavior is same and no information concerning the configuration of a shared network is indicated to the UE. VLANs are used for traffic separation at eNodeB (one VLAN per operator).
S1-flex interface is to enable connection of each eNodeB to all EPC nodes within a pool area (TS 36.401: An MME pool area is defined as an area within which a UE may be served without having to change the serving MME. An MME pool area is served by one or more MMEs, aka “pool of MMEs”, in parallel. MME pool areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other). In FIGS. 4a and 4b, the dashed cells (ovals) are the cells shared between the two operators and the dashed MME boxes are the shared MMEs. S1-flex is an equivalent of the Iu-flex 3 G/UMTS option.
If the E-UTRAN is shared by multiple operators, the system information broadcasted in each shared cell contains the PLMN ID of each operator (up to 6) and a single tracking area code (TAC) valid within all the PLMNs sharing the radio access network resources. Based on system broadcasts, the UE selects the desired PLMN and reports it to eNodeB during RRC connection setup. The eNodeB includes the selected PLMN in the INITIAL UE MESSAGE while sending it to the MME. The MME indicates the selected core network operator PLMN ID to the UE in the GUTI during initial attach procedure. Once attached to an MME, the UE shall be able to indicate the allocated MME in subsequent instances of the random access procedures. The indication of the allocated MME code, MMEC, is contained in the temporary UE identity.
Positioning node receives PLMN ID of the current cell of the target UE as a part of the Enhanced Cell Global Identity, ECGI, information, a mandatory field in LCS-AP as indicated in 3GPP TS 29.171.
LMUs are typically costly. Thus, UTDOA deployment can incur high capital expenditures. Therefore, operators are interested in LMU sharing, i.e., share LMU deployment across multiple PLMNs (Public Land Mobile Network). However, in standardization discussions (e.g., 3GPP RAN 2/3 discussions), it is not yet clear for multiple PLMN UTDOA deployment in LTE, how the nodes with positioning functionality (e.g., LMUs, E-SMLC, LMU gateway, coordinating node) should interwork with:                general-purpose network nodes, including radio network nodes, which may or may not be shared by the operators and/or may be operated by other operators than those operating the LMUs; and        other logical/physical positioning nodes that belong to different PLMNs.        
Also, there is as of yet no known techniques to select measuring nodes and coordinate positioning measurements in multi-PLMN scenarios, which may make it difficult for operators to achieve network sharing benefits for positioning.